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ABSTRACT 


The  concept  o*  DB*S  architecture  -h-a-fc>  played  an  important  role  in 
the  design,  analysis,  and  comparison  ct  DBMSs  as  yell  as  in  the 
ceve lopment  of  other  database  corcepts.  The  ANSI/SPARC 
prototypical  database  system  architecture  -as  a  major 
cortricution  in  this  development.  The  architecture  raised  many 
issues,  stimulatec  considerable  research,  and  poseo  a  number  of 
nr,  protlems.  Since  the  basic  formulation  gf  ^  the  ANSI 
architecture,  in  1974,  little  consideration  -H  a  s-  beep>  given  to 
resolving  problems  and  accommodating  neu/and  future  developments. 
The  main  problems  concern  its  unnecessary  ridgidity. 

The  contributions  cf  this  paper  are  a  distinction  between  DBMS 
framewcrk  and  DBMS  a r c h i t e c t u r e  ,  and  a  functional  DBMS  frame-ork. 
The  frame-ork  was  developed  using  a  fuhcticnal  approach  in  -hicn 


a  DE"rj  is  characteriyed  abstractly  in  terms 
co mp cn ?n t s  and  their  potential  r e  l  a t  ion s h i p s  . 
basec  cn  the  notions  of  modularity  and  oata 
oevelocea  in  software  engineering  and  p rog r amm i ng 


of  functional 
The  approach  is 
abstraction  as 
languages . 
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INTRODUCTION 


■hen  designing  a  rew  database  management  system  (DEWS),  its 
functions*  database  model*  architecture*  ana  languages  must  be 
cefirec.  This  inevitably  deals  with  beth  logical  and  physical 
aspects*  the  way  cf  fitting  together  ecoules  of  the  system  in  an 
overall  system  architecture.  In  earlier  approaches*  DEPS 
architecture  appears  to  have  been  inextricably  tiea  tc  the 
philosophy  and  database  model  of  the  system.  Architecture  has 
been  treated  as  a  pervasive  feature  cf  a  DEMS.  The  purpose  of 
this  poDer  is  to  distinguish  a  DD“S  framework  (which  may  be 
considered,  informally,  tc  be  an  abstract  c ha r a c te r i z at  ion  of  a 
D9!*S  --  its  functicns*  objects,  and  larcuage  interfaces)  from  a 
0  91'*$  architecture  (which  is,  again  informally,  the  way  that 
mocules  are  assemolec  to  achieve  a  system  that  implements  the 
features  specified  in  the  framework).  An  architecture 
inaeperdent  framewerk  is  developed  here  to  provide  a  better 
mechanism  for  comparing  systems  that  purport  to  achieve  the  same 
goals  (but  actually  co  not,  tecause  of  their  architecture). 

Possibly  trie  most  ciscussed  DBMS  architecture  in  the  past  five 
years  has  been  that  proposed  by  the  ANSI/SPARC  ad  hoc  group  on 
catacase  managemert.  This  group*  ccnverec  in  1972*  was 
originally  chartered  by  the  American  National  Stancards 
Ins t  i  t ut e-X 3-S P a R c  conmitee  to:  Investigate  the  subject  of 
database  managemert  systems  with  the  objective  of  determining 
which,  if  anjr,  aspects  of  such  systems  are  a£  suitable 
candidates  for  the  development  of  American  National  Standards. 

The  major  result  of  the  group  was  the  so-called  "three  schema 
u r c h  i  t e c t u re".  This  was  epitomized  by  the  diagram  (Figure  1) 
copied  from  the  interim  and  final  reports  [ANSI  1975;  Tsichritzis 
ana  Klug  197E3.  The  work  has  been  characterized  as  "a  database 
system  prototypical  architecture”  ir  which  D9MS  functions  were 
cescrihea  in  a  somewhat  ad  hpc  fashion,  along  with  a  aiscussion 
of  an  "aostract  implementation".  The  group  was  never  in  total 
agreement  as  to  the  language  interfaces  and  architectures 
presented  in  the  report.  The  final  report  reflected  more  of  a 
consensus  position  w'ithout  much  of  the  ancilliary  argument.  I  n 
conseauence,  the  report  has  been  argues,  discussed,  ana 
interpreted  by  many  who  have  only  these  reports  as  tackaracuo 
(i.e.,  i  very  small  part  of  the  work  of  the  group). 

lecaus*  the  "A  fa  SI/SPARC  architecture"  filled  a  gao  or  satisfied  a 
ph  i  i  cs oo h  i  c al  neec  of  users  and  researchers,  it  has  been 
successful  (as  a  concept,  if  not  as  a  prototype  for  the  future 
implementors).  However,  the  lack  of  clarity  has  led  to  some 
substantial  differences;  moreover  there  are  problems  with  the 
architecture  (to  be  discussed  later).  it  seems  that  the  problems 
stem  partly  from  the  fact  that  ar  architecture  involves 
implementation  details.  Thus,  we  reed  a  more  abstract  yet 
precise  ckaracteri aat  ion  of  a  DBMS. 
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In  tcth  cases*  data  semantics  (logical  properties  of  objects) 
should  oe  considered  independan t  ly  of  the  underlying 
repres ent at  ion  anc  it  should  be  possible  to  alter  the 
rep r es en t at  ion  without  altering  the  data  semantics*  This  has 
been  pursuea  in  programming  languages  under  the  name  dg£a 
abjtracijgn  and  in  databases  under  the  rame  of  data  ingggjn gen £g . 
In  this  paper*  we  apply  these  concepts  to  DBMSs. 


I 

I 

!. 


on  ion 


ANSI  —  Prototypical  Architecture  Schematic 
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1.1.  Definitions  cf  framework  and  Architecture 


*  25!!j£  framework  is  defined  as: 

*  paradigm  or  model  of  the  functicrs  of  a  D6*S.  The 
functions  may  be  defined  in  terms  of  functional 
components  anc  their  possible  relationships. 

The  definition  is  tased  on  the  functional  approach  in  which 
computer  systems  are  characterited  abstractly  in  terms  of  their 
functions.  The  important  concepts  for  the  above  definitions  are: 

1.  a  functional  definition  is  mere  abstract  than  an 

architecture  since  it  provides  a  specification  of  a  class 
c*  oossible  ar c h  i  t e c t u r es  in  which  the  functions  can  be 
imp  l  emen  ted. 

2.  a  DE“S  is  defined  in  terms  of  its  functional  components 

which  include  the  languages  used  to  express  and  initiate 
the  functions  (i.e.,  the  syntax  associated  with  the 
component)  ana  both  the  functions  themselves  and  the 
objects  they  reference  (i.e.,  the  semantics  of  the 
component).  The  objects  are  normally  items  in  groups  of 
cata  that  exist  as  input,  output  or  in  a  database.  A 

functional  component  can  be  viewee  as  an  abstract  machine. 

3.  The  components  are  modules  that  encapsulate  well  definea 
functions  ard  their  objects  (cata)  in  a  self-containea 
unit.  A  component  is  a  unit  of  thought  or  understanding. 

4.  a  particular  DB«S  will  realise  their  functional  components 

IS  software  modules.  These  components  may  te  either 

integrated  irto  one  component  or  relateo  through  mapping  or 
t rars format i ens  (c.f.,  database  transformation  processors 
in  the  ANSI  arch  ite cture )  .  In  a  framework,  the  potential 
rather  than  actual  relationships  should  oe  defineo,  thereby 
.allowing  design  variations  for  efficiency. 

•  The  functions  of  importance  in  cersidering  a  DENS  framework 
are  those  that  are  usee  by  humans  and  pieces  of  software 
♦rom  the  highest  level  application  user  down  to  the  lowest 
level  machine  interface  through  a  number  of  functional 
components  or  abstract  machines. 

6.  The  language  provides  the  syntax  used  to  express  ana 
initiate  the  functions  on  the  ctjects.  Abstract  syntax 
fNcCarthy  1^623  should  be  used  to  avoid  unnecessary 
syntactic  detail. 

*  ilSbllEiiy E S  is  defined  as: 

The  details  of  the  implementation  cr  realization  of  the 
functional  components  cf  a  particular  DBN$  incluoing 
t*e  aggregation  or  grouping  of  the  functional 
components  irto  system  componerts  as  well  as  the 
r e l at  ions h  ips  between  these  components. 
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This  definition  assumes  that: 

1.  5  fr  3«e»ork  characterizes  or  specifies  the  functional 
components  to  be  realized  in  a  particular  architecture  . 
There  may  te  many  architectures  that  fulfill  the 
so e c i 4 i c at i o r s  of  a  given  framewcrk. 

2.  The  framework  may  be  considereo  as  a  specification  of  the 
philosophy  and  goats  for  a  DBMS,  while  the  architecture 
represents  the  design  of  system  components  to  satisfy 
implementation  objectives  (e.g.,  run  time  efficiency,  rapic 
response,  fast  rec o ve rab i l i t y ,  and  protection  against 
security  viclation).  Naturally.  cifferent  architectures 
provide  different  likelihoods  of  achieving  tne  furctionally 
cefined  goals  of  the  framework. 


1.2.  The  Need  to  Separate  framework  arc  Architecture 


A  05*$  framework  can  be  usee  to  determine  whether  a  software 
package  is  or  is  rot  a  DBMS  Ci.e.,  it  cef ires  a  class  ct  objects 
called  D6*Ss).  The  framework  says  what  is  recuireo  for  a  DBMS  <j 
architecture  shows  how  this  is  implemented. 

As  already  discussed,  the  concepts,  terms,  and  implementation 
features  of  D  13  "*  S  s  are  still  evolving.  They  prooafcly  will  evolve 
for  some  substantial  time.  however,  there  has  already  been  a 
call  for  standardization  of  data  manipulation  languages  and  data 
definitior  facilities  (this  in  the  USA  is  urder  ANSI  X  3  J4  CCBCL, 
X3J3  FORTRAN,  anc  x2M2  Data  Definiticr  Language  Commitees).  It 
is  worth  asking  now,  how  these  efforts  may  affect  the  future 
anc  inaeed  whether  some  aspects  cf  the  standards  concern 
arch it£ cture  (which  presumably  would  be  wrong  since  it  specifies 
howl  rither  than  framework  (which  is  allowable  since  it  specifies 
what).  Tt  is  necessary  to  characterize  DBMSs  in  an  abstract  yet 
unicue  way.  3y  analogy,  the  early  development  of  programming 
languages  needec  the  concept  of  a  language  translator  (as  its 
framework)  to  provide  a  method  for  describing  the  implementation 
of  particular  compilers. 

The  re -  sons  for  a  DBMS  framework  are  thus: 

1.  to  aid  in  un ce r s t and i n g  DBMSs,  from  a  standpoint  of  their 
•efinitional  and  conceptual  goals. 

2.  t0  ®ake  it  posible  to  define  arc  specify  the  neeos  as  the 
’irst  phase  cf  the  design  process. 

2.  To  allow  the  analysis  of  existing  DBMSs  at  a  hiqh  level  o* 
functionality  rather  than  at  the  ’performance"  level. 

4.  To  provide  a  means  for  futher  research  in  topics  such  as 
cata  dictionary  (meta  data),  mappings  between  different 
objects  (translation  of  data  and  meta  aata),  semantic 
database  modelling  and  distrubutec  DB*Ss. 

5.  To  permit  the  abstract  comparisor  of  DBMSs,  ince pendent  d 
architectural  details. 

The  eain  reason  for  a  D°MS  architecture  definition  is: 
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To  provide  a  uniform  aetnoa  for  c ha ra c t e r  i  z  i  ng  a  particular 
implemented  C9MS. 

However,  when  taken  together,  the  framework  and  architecture 
a  l  sc  : 

2m  Allow  study,  analysis,  and  comparison  of  different  CBi*Ss 
■ith  and  without  architectural  details, 
hence  a  DBMS  framework  can  be  used  to  ccoroinate  the  development 
of  cifferent  D8“S  architectures  within  a  family  of  OEMS  stanoaras 
(e.g.,  to  achieve  the  needs  of  (Jeffery  et  al.  19793). 

It  wilt  be  possible  to  see  whether  new  DBMSs  fit  within  an 
existing  architecture,  cr  need  a  new  dsfinition  of  the 
architecture  to  allow  the  system  to  "fit"  (e.o.,  as  ciscusseo  in 
t8erg  197&3K  It  will  also  be  possible  to  investigate  how  a  set 
of  rather  different  implementations  ct  DBMSs  are  similar  or 
differ  (e.g.,  an  attempt  is  now  uroer  way  by  the  author  ano 
others  to  compare  cifferent  "relational"  systems  in  order  to 
cetermine  a  nucleus  of  functions  arc  objects  for  a  relational 
DBMS  ). 

It  is  interesting  to  note  that  the  methcas  of  this  >ap er  apply 
elsewhere.  the  emphasis  here  is  on  D E  M> ,  tut  the  method  applies 
to  all  automated  information  systems  (and  possibly  wicer). 
However,  the  following  is  the  aim  of  the  framework  in  DBMS  terms; 


Tc  reflect  anc  capture  both  current  state-of-the-art 
ard  research  ideas  concerning  DBMSs,  as  well  as  to 
suocort  the  evolution  of  08  MS  corcepts  and  new  OEMS 
met  hods. 

This  aim  is  analogous  to  the  one  in  which  programming  language 
technology  has  beer  captured  and  supported  through  the  conceptual 
language  translators.  As  an  apparent  tantology  at  present,  but 
exparded  in  the  latter  part  of  this  paper,  we  define: 


A  DB^S  is  a  computer  based  system  that  implements  or 
supports  database  management  furctions  oefineo  in  the 
DI-MS  framework  by  means  of  a  coherent  D  PM  $ 
architecture. 


1.3.  celevant  Research 


The  concepts  underlying  the  terms  DBms  framework  and  06*i> 
architecture  nave  figured  largely  in  CFMS  research.  The  idea  of 
surveying  and  analyzing  D8MS  features  originated  earlier,  but 
came  to  fruition  in  the  C0O*$TL  systtxs  committee  work  [CCD»SYl 
iBfcg,  19*13.  This  work  was  an  attempt  at  learning  the 
similarities  and  differences  betweer  DB¥Ss»  hot  the  least 
treble*  in  doing  this  was  a  definition  cf  the  term  DBMS  itself. 
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This  work  aistinguished  a  two  level  "architecture":  data 
structures  and  storage  structures. 

In  1  9  7  c  the  ANSI  group  started  its  work  at  the  beginning  c<  a 
oecace  of  rapid  development  in  the  database  area.  The  *NSI  three 
schema  architecture.  which  was  very  influential  in  the  perioo. 
was  used  as  a  basis  for:  a  "new  generation"  of  DEMSs  Thijssen 
1976,  1  9  7 73,  multiple  view  support  [Mug  anc  Tsichritiis  197  63, 
intergrating  programming  ana  datatase  languages  in  the 
ce ve  lopment  of  user  interfaces  [Date  19763.  ana  the  development 
of  distributed  DBMSs  [«eil  ana  Holler  19783.  Theories  ana 
methods  of  mapping  between  conceptual,  external,  and  internal 
levels  were  developeo  [®aol  ini  1  977, 19  £C;  Muq  19783  . 

Since  1974  there  have  teen  few  contributions  to  framework  ana 
architecture  issues  ger  se.  However,  it  is  now  eviaent,  as 
cescrited  in  the  next  section,  that  the  ANSI  architecture  is 
inadequate  to  accoamodate  current  DBMS  concepts  ana  future  neecs. 
Ha  nr.  mer  ana  "cleoc  have  quest  i  oned  the  two  decade  old  DE“S 
paracigm  and  arauec  the  neec  for  a  new  architecture  based  on  a 
federation  of  loosely  couplec  databases  [Hammer  ano  McLeod  19793. 
The  National  bureau  of  Stanoards  has  proposed  criteria  for  a  ne- 
architecture  [Jeffery  et  .  al.  1979;  Eerg  19783  not  met  by  the 
ANSI  architecture.  In  this  paper  the  concept  of  DBMS  frameworx 
is  developed  to  adcress  the  above  issues. 
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Re  cu  i  re«ent  s  of  a  DB*S  framework 


There  is  no  doubt  that  the  ANS1/SPARC  report  contributec  to  D£*S 
architecture  and  theory.  The  report*  hcwever,  raises  some  issues 
that  it  does  not  address*  and  ignores  others  that  it  should. 
This  section  gives  some  concepts  that  a  framework  shoulc  incluce, 
tut  that  were  missing  or  deliberately  left  cut  of  the  report. 


2.1.  Contributions  of  the  ANSI/SPARC  Architecture 


The  ANSI/SPARC  stucy  group  or  DBMS  presented  a  comprehensive  vie- 
of  a  d£^S  from  the  highest  (user)  to  the  lowest  (oevice)  level. 
It  icentified  several  important  human  "roles";  processing 
functions;  interfaces  (human,  software  and  haroware);  the  flew  of 
cata,  commands*  program  modules,  arc  descriptions  between 
processes  and  people;  mechanisms  for  program  preoeration  ana 
execution;  and  finally  the  concept  of  a  prototype  data 
ci ct  iorary.  The  significant  conclusions  were  that: 

1.  the  particular  database  model  was  not  important  in  the 
architecture. 

2.  There  were  three  important  levels  of  data  Definition 
(schema):  external*  conceptual,  and  internal.  moreover, 
that  their  use  imorovec  uata  independence. 

2.  The  levels  ana  their  associated  processing  functions  could 
te  associatec  with  proper  playinc  the  roles  of  application, 
enterprise  and  database  adm ins t r a  to r s  respectively. 

4.  There  must  be  mappings  or  t r an s form  at  ions  between  these 
multiple  data  definitions  (schema)  and  thus  in  processing 
the  objects  *s  they  pass  to  ana  fro*  the  database. 


2.2.  Problems  of  the  ANSI/SPARC  Approach 


In  the  light  of  more  recent  work,  it  is  possible  to  develooe  an 
approach  that  better  fulfills  the  criginal  (and  so*e  new) 
objectives  for  ch a r a c t er i z i ng  a  DBWS.  The  following  ten  (10) 
issues  were  raised  but  not  resolved  by  the  ANSI  a r ch  i  t e c t u r e  . 

1 .  Its  S t ryct u ra  l  Agggrach 

The  group  attemped  to  fulfill  their  framework  objectives  by 
cefirirg  a  prototypical  architecture.  As  an  architecture ,  it  rot 
only  told  whaj,  a  DB^S  did,  it  alsc  inoicated  hgw  such  a 
woulc  le  implemented.  Their  approach  was  sjryg£yral  in  that  it 
emphijed  system  structure  over  system  function.  The  result  in, 
architecture  is  not  sufficiently  abstract  to  be  a  framework.  It 
is  overly  complex  (as  indicated  by  the  fact  that  only  the  central 
thirc  is  discussed)  and  does  not  accommodate  all  usable 
implementations  (e.g.,  a  database  machire  or  associative  memory). 
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This  leaos  to  the  first  requirement  for  a  gcod  DBMS  framework: 
Requirement  h  c  1  i 

*  D8MS  framework  should  accommodate  a  spectrum  of  DBMS 
a r c h  i  t e c t u r e s  .  It  must  not  be  dependent  on  haroware  or 
software  technology,  to  achieve  longevity  in  terms  of 
r  ;  o  i  d  t ec hno  l  eg  i  c a l  advances.  It  must,  however,  be 
atle  to  accommodate  other  levels  of  detail  that  are 
associated  with  some  abstract  or  concrete  machine. 


c .  Structyrai  i£E£23£t  £2  database  D  e  3 crjgticn^ 

In  keeping  with  the  traditional  structural  approach,  the  AVSi 
architecture  emphiasi2es  structure  over  function  with  regard  to 
oatatase  definition.  Schemas  are  described  as  consisting  ot 
inscriptions  of  database  structure  plus  security  constraints  anc 
"administrative  fiats".  The  data  dictionary/directory  consists 
o*  similar  structural  and  control  information. 

Recert  research  on  semantic  catabase  mccels  [frodie  197?;  Biller 
anc  Neuhcld  1978  ;  Hammer  and  WcClecc  19',8Z  catabase  mocelling 
13 rcci el  979;  Wasserman  19SG;  Weber  19781,  OEMS  implementation  anc 
catabase  maoping  Cnlug197R;  Paolini  1  977,  198C}  indicates  the 
need  for  more  than  simply  structural  information  in  the  schema. 
A  schema  shoulo  describe  the  complete  semantics  of  a  view  of  the 
catabase.  Hence,  it  shoulo  include  the  oasic  functions  as  well 
as  the  basic  structures  of  database  objects. 

The  cortent  ,  nature,  f un ct i ona  l  i  t y  ,  anc  re l at  ionsh  ip s  of  schemas, 
schema  processors,  schema  transforms,  ard  cata  dictionary  of  the 
A  hi  SI  architecture  are  liable  to  alter  in  time.  Also  the  various 
humar  "roles"  will  change.  This  leads  to  a  need  tor  change  in 
the  system  structure,  hence  requiring  a  new  architecture.  Thus 
w  e  have: 


R“quiremgnt  Ng. 

A  D B * S  framewerk  should  accommodate  (semantic)  schemas 
that  describe  function  and  structure. 


I2ck  St  £mfihasis  gn  QtijtSlS 

The  architecture  character! zes  various  roles,  human  interfaces, 
anc  processing  functions  initiated  through  the  interfaces.  It 
uoes  net  make  clear  what  objects  are  refered  to  by  each  function 
hence  the  roles  ana  the  interfaces  are  not  easily  unoerstoco. 
For  example,  an  applications  programmer  deals  with  external 
datatase  objects  while  an  application  systems  adminstrator  deals 
with  objects  that  constitute  an  internal  schema.  The 


1 


architecture  also  includes  relationships  tetween  processors. 
These  retails  should  be  of  no  direct  ccrcern  to  people  in  roles. 
The  objective  of  data  independence  ircicates  that  people  should 
be  concerned  with  what  functions  and  otjects  are  available.  Thus 
■e  have: 


Regyirjwent  3 g 

The  DB*S  framework  must  include  the  definition  of  which 
functions  refer  to  (use  or  generate)  which  objects  by 
weans  of  which  language  elements.  In  the  funct’onal 
acorcach,  objects  are  included  explicitly. 

4.  I»E!  ieg  Hxed  Number  of  ^ e v e_l  s 

The  ANSI  architecture  distinguishes  at  least  three  schema  levels: 
external,  conceptual,  and  internal.  The  reports  argue  that  the 
cistinction  was  made  to  facilitate  oata  independence.  The 
reports  also  indicate  multiple  levels  of  external  schemas, 
however,  it  is  not  clear  how  multiple  external  schemas  (let  alone 
multiple  levels)  are  accommooat ed . 

Just  as  there  are  logical  cons i der at i cns  for  having  multiple 
levels  of  external  schemas,  there  are  physical  or  implementation 
reasons  for  having  multiple  levels  of  irternal  schamas.  In  both 
cases,  0 ist in gu i s hi ng  more  levels  or  functional  components  may 
contribute  to  data  independence.  The  specific  number  cf  levels 
of  abstraction  is  an  a r c h i t ec t ura l  cesign  consideration  not  an 
aspect  of  a  D9NS  framework.  Thus  we  have: 


B  f gu  i  r rmjn t  Nc ,  4j 

T*»e  DS^S  framework  should  accommodate  an  arbitrary 
number  of  levels  of  system  compcrents.  The  levelling 
of  a  particular  DB¥S  is  an  importart  character! st  ic  of 
its  archi tect ire  . 

5.  £i*fd 

The  ANSI  architecture  defines  a  number  cf  human  roles.  A  role  is 
defired  py  a  collection  of  functions  needed  to  fulfill  certain 
tasks.  However,  the  aggregation  of  functions  into  specific  roles 
is  not  sufficiently  flexible  to  be  a  generic  characterization. 
As  indicated  earlier,  the  roles  are  still  evolving.  Particular 
09  f*  S  s  aggregate  cr  group  functions  differently  to  support  roles 
appropriate  to  the  philosophy  of  the  systems;  the  roles  supported 
by  C  CD  a  S  YL  like  systems  (e.g.,  UNlVAC's  Oh'S  11GC)  are  similar  to 
these  in  the  architecture,  whereas,  S>STE*-R  supports  different 
roles  which  are  more  in  keeping  with  Ccod's  principle  of 
homogeneity  or  uniformity.  Also,  there  is  considerable  research 
aimec  at  automating  some  of  the  proDOsec  human  roles.  This  need 
tor  a  variation  in  roles  produces: 
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R i rgmgn t  V  5  .  5  : 

*  05MS  framework  should  te  based  cn  functions  rather 
t  l,an  on  their  aggregation  into  roles.  The  framework 
should  not  bias  the  initiation  of  the  functions  towards 
humans  or  pieces  of  software. 

c  .  $  t  a  t  _i  c  Maggjnjjs 

The  importance  of  maopings  between  objects  was  emphasized, 
however,  little  cetail  was  given.  The  interim  report  discussed 
static  Ci.e.,  structural)  maps  or  transforms  between  object 
"descriptors"1  in  schemas.  Research  instigated  by  the 
architecture  indicated  the  nets  for  dyr.mic  (i.e.,  procedural)  as 
well  as  static  maps.  Maps  may  exist  between  languages,  functions 
(i.e.,  programs)  3rd  database  objects.  Maps  can  be  usee  in 
establishing  equivelence,  subsets,  "uses"  CPamas  ">972  3  ana 
descriptive  relationships  between  objects.  Such  a  spectrum  ol 
maps  is  not  reflected  in  the  ANSI  arch  i  tecturt.  Thus: 


R “gu  i  r ement  Vc.  6  g 

A  DBMS  framewerk  should  accommodate  a  spectrum  of  maps 
by  indicating  potential  re lat i c rsh  ips  and  ignoring 
details  of  how  a  map  is  realized. 

7«  kaci  ei  Isesasis  s c  Uicayaass'lnisiiisss 

The  architecture  centained  ever  fourty  interfaces  between  roles 
ana  processing  facilities.  Textual  cescriptions  of  interfaces 
descriceo  the  objects  and  operations,  tut  there  was  little  detail 
on  the  nature  of  the  language  (i.e.,  the  forms  of  its  syntax,  the 
usage  mode,  or  the  way  in  which  specific  functions  coulc  be 
initiated).  This  leads  to: 


R f gu^r emen t  N  c  .  7  j 

A  D9^S  framework  should  accommccate  a  spectrum  of 
languages  or  interfaces.  A  language  is  characterized 
by  some  abstract  syntax  and  is  used  tc  express  and 
iritiate  functions  over  DB^S  objects. 


c .  the  Nature  gf  the  Database  Siiiionar^ 

The  concept  of  a  database  d  i  ct  i  on  a  ry  fa  i  r  ec  t  o  r  y  (ED/t>)  as 
presented  in  the  architecture  is  somewhat  naive.  The  concept  01 
o  30/0  has  long  ceen  known  to  have  mere  potential  than  as  a 
repository  for  schemas  ana  their  r e  lat i onsh ips  .  In  fact,  the 
idea  of  a  directory  for  distributed  systems,  cf  a  multiplicity  of 
database  models,  etc.  have  all  been  seen  as  part  and  parcel  ot 
the  meta  database  --  which  may  or  may  not  by  implemented  within 


the  same  03**S  (though  there  are  obvious  advantages  for  aoing  so). 
These  *ore  recent  ideas  were  excluded,  giving  rise  tc: 


5  llSISOl  5!Si  ii 

A  OB^S  f  raxevork  should  accommccate  a  mch  higher 
philosophy  cf  meta  objects  and  their  control* 
f on c t i ona l i t y  and  relationships.  The  seta  objects  have 
a  distinct  relationship  to  the  objects  they  describe, 
ard  the  concept  of  higher  semantics  of  data  should  be 
easy  to  incorporate. 

<? .  brr esglyed  £once£tyal  and  External  Jssyes 

The  architecture  raised  a  nueber  cf  problems  concerning 

conceptual  and  external  schemas: 

1.  .hat  is  a  conceptual  schema  structure  ? 

2.  Is  there  a  conceptual  database,  and  if  so,  are  there 
conceptual  functions  ? 

2.  «re  external  schemas  always  mapped  through  the  conceptual 
schema  ? 

4.  are  external  schemas  subsets  cr  derivations  of  the 
conceptual  schema  ? 

The  architecture  dees  not  provide  an  answer  for  these  Questions: 
researchers  have  examined  many  cf  the  alternatives.  In 
particular,  there  are  good  reasons  tc  support  multiple  itut 
eauiue  lent)  conceptual  schemas  as  oppesed  to  a  single  conceptual 
schema  in  the  ANSI  a r c h i t e c t u re .  This  leads  to: 


2£2yi££E£Dl  2 Si  2i 

A  DBMS  framework  should  accommccate  a  spectrum  of 
conceptual  anc  external  levels. 

1  j  .  Distribyjgg  £  <3 1 3  8  3  5£  § 

The  architecture  did  not  attempt  to  address  the  protlem  of 
cistricuteo  systems.  It  contains  single  conceptual  ano  internal 
schemas.  However,  for  performance  reasons,  such  as  those  that 
arise  in  distrubuted  systems,  partitions,  replications  or  partial 
t r an s f c r m at  ions  of  the  internal  schema  might  be  distributed  witn 
the  cata,  leading  to: 


SS2yi££S£Di  2  £  £  IQi 

A  DBAS  framework  should  accommooate  distributed 
d  it  abases  through  permitting  multiple  schemas  and 
dJtabases  at  the  internal,  conceptual,  and  external 
levels. 
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3.  Th»  Functional  fraoe^ork 


3.1.  The  Functional  Approach 

A  computer  based  system  can  be  described  in  terms  of  the 
functions  it  performs  anc  the  objects  over  which  the  functions 
operate.  Frequently  a  dichotomy  arises;  the  traditional  approach 
to  database  management  has  emphasizec  structural  descriptions 
<e.g.t  schemas)  whereas  the  approach  tc  programming  languages  has 
emphasized  behavioural  descriptions  (e.g.,  data  abstraction), 
fcut  ty  considering  a  primative  Turning  Machine,  it  is  apparent 
that  rnither  states  nor  the  state  transitions  alone  provice  an 
adecuate  character  izat  ion.  Indeed  the  benefits  of  structural 
versus  behavioural  representations  of  krowledge  have  been  oebatej 
extensively  in  artificial  intellegence  without  resolution. 

In  the  approacn  taken  here  both  functions  (behaviour)  ana  objects 
(structure)  are  irtegrated  in  one  framework.  Functions  ana 
objects  are  closely  related,  and  functions  are  relatec  to  ether 
functions  through  objects,  while  objects  are  reLateo  to  each 
other  via  functions.  Objects  can  te  realizec  only  through 
functions  and  functions  have  no  meanint  with  out  objects.  In  the 
algebraic  spe c i f  i  ca t  i  on  technique  CGuttag  19753  functional 
composition  is  applied  to  oojects  (cr  states  S)  to  produce  new 
objects  <i.e.,  fCKS),  f1(fC(S>>,  ...,  frC  ...  1 0  <  S )  ...)).  The 
approach  taken  here  permits  both  sices  of  the  function  versus 
object  dichotomy  but  balances  one  with  the  other. 

The  functional  framework  is  thus  a  paracigm  or  model  of  a  DPmS  in 
terms  of  its  furct  ional  components  and  their  potential 
re  l  a t i ens h  ips .  The  functional  aspect  is  derived  from  data 
abstraction  in  which  objects  are  cefined  completely  ana 
abstractly  by  the  functions  availatle  on  them.  The  component 
aspect  is  derived  from  the  modular  approach  to  the  corstruct  ion 
of  software  systems.  A  functional  component  is  cefined  by 
language  functions,  and  objects.  The  functional  component  "X" 
represented  as  in  Figure  2. 


FtaitE  2:  Functional  Cowonent  Schematic 
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The  functions  Fx  are  the  operations  to  be  performeo  by  the 
component.  The  objects  Cx  are  those  defined  by  (i.e.,  realizable 
through)  the  functions.  Fx  and  Ox  constitute  the  "semantic”  or 
meaninc  of  componert  "X".  The  language  Lx  is  the  means  through 
which  the  functions  are  initiated  and  the  objects  are  referenced. 
Lx  corst  itutes  the  Syntax  of  the  functional  component  M  X  *' .  In 

Figure  ?  ,  the  line  Lx - Fx  can  be  reac  as  "initiates".  The  line 

Fx---- Cx  means  "uses"  or  references. 

A  functional  component  defines  what  functions  are  to  be  performed 
on  shat  cojects.  Details  of  how  functions  or  objects  are 
realized  are  excluded  from  a  single  component  but  may  be 
expressed  through  the  potential  r el  a t i c r s h i ps  among  components. 
Examples  are  shown  in  Figure  3. 


Figure  3:  Functional  Comment  Examples 


In  order  to  answer  the  question:  what  functional  components 

constitute  the  Da*S  framework,  it  is  necessary  to: 

1.  Consider  all  objects  of  interest  to  the  DE*S. 

“.  Consider  what  basic  or  funoamental  functions  can  be  applieo 
to  any  of  these  objects. 

? .  Oevelope  the  framework  by  considering  each  basic  function 
over  each  object.  This  produces  e  matrix  of  objects  versus 
functions  ir  which  each  entry  represents  a  functional 
component  Lx - -Fx - Cx. 


3.2.  rbjects  in  a  DE*S 

There  are  two  kinds  of  objects.  first  there  are  otjects 
associated  directly  with  the  application  database  (i.e.,  the 
database  itself,  the  database  schema,  and  programs  over  the 
oatabase).  Secono,  there  are  objects  indirectly  associated  with 
the  database,  primarily  for  control  reasons  (i.e.»  access 


control*  system  logs*  data  dictionary). 

First*  consider  objects  associated  directly  with  the  application 
oatabase.  There  are  three  types  cl  level  called  e*t£rn$|, 
£2D£f  »  ana  internal,  respectively. 

3.2.1.  External  Objects 


These  consist  of  all  logical*  application  specific*  objects 
(i.e.,  entities,  relationships,  functions)  of  interest  to  a 
particular  application  or  user  group  (i.e**  all  objects  refereo 
to  ty  functions  meaningful  to  a  given  application).  External 
objects  are  derivec  from  (i.e.,  mappable  to)  conceptual  objects* 
They  constitute  "external"  aata bases,  and  are  oefined  in  an 
•‘external”  schemas. 

There  ny  oe  many  external  databases  anc  schemas;  both  different 
external  schemas  for  one  conceptual  schems  and  different  levels 
of  external  schemas  on  any  given  conceptual  schema.  The  purpose 
of  the  external  level  is  to  provide  problem  oriented  objects  in 
the  most  convenient  manner  to  a  user  group  and  facilitate 
mocification  and  creation  of  application  oriented  objects  in 
agreement  with  the  evolving  needs  of  the  enterprise.  External 
objects  are,  of  course,  realized  through  external  functions. 

3.2.2.  Conceptual  Objects 


Conceptual  objects  are  those  logical  cbjects  (e.g.,  entities, 
r e l a t i cns hips ,  functions)  of  interest  tc  an  enterprise,  (i.e.»  to 
all  current  ana  potential  applications).  At  a  minimum,  the 
conceptual  objects  are  those  from  which  all  current  external 
cnjects  are  derivea.  Conceptual  otjects  have  the  properties 
common  to  all  external  objects  but  net  the  pecu  l  i ar i t i es  of 
particular  external  "views".  Conceptual  objects  are  defined  in  a 
conceptual  schema  and  constitute  the  conceptual  database.  The 
conceptual  database  way  never  be  realized  since  there  may  be  no 
language  through  which  to  initiate  ccrceptual  functions.  There 
may  be  many  "eauivalent"  conceptual  schemas  ever  the  same 
conceptual  database.  These  would  differ  only  in  the  database 
mocel  used  to  defire  the  schema. 

The  purpose  of  the  conceptual  level  is  to  support  the  cefinition 
anc  control  of  objects  of  interest  to  an  enterprise  to  achieve  a 
degree  of  data  independence.  In  particular*  it  provides  a  casis 
for  consistency  anc  semantic  untearity  cf  external  levels  tBrooie 
19723  and  provides  a  level  of  indirection  between  internal  ana 
external  levels. 

3.2.3.  Internal  Objects 


Intern  it  objects  are  all  those  used  by  the  pews  to  implement 
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conceptual  and  external  objects  (e.g.,  records  •  files,  access 
paths,  indexes,  anc  utilities)*  The  requirements  for  internal 
objects  are  established  primarily  by  the  properties  of  the 
external  and  conceptual  objects  anc  by  the  implementation 
philosophy.  They  are  defined  in  an  internal  schema  ana 
constitute  an  internal  database.  As  with  external  schemas,  there 
may  be  different  internal  schemas  for  ere  conceptual  schema.  It 
is  f  reouent ly  the  case  that  there  are  several  layers  of 
abstraction  or  internal  levels  associated  with  each  “internal 
view". 

The  internal  levels  are  the  layers  of  abstraction  usee  to 
implement  conceptual  and  external  databases  on  some  underlying 
abstract  machine. 

3.2.4.  External,  Conceptual,  and  Interral  Levels 


In  general,  a  D9MS  can  have  multiple  external,  conceptual,  ana 
internjl  levels.  There  may  be  multiple,  but  equivalent 
conceptual  schemas  over  one  conceptual  catabase.  Tor  both  the 
externyl  and  internal  levels  there  may  be  multiple,  different 
"views”,  as  well  as  a  number  of  levels  for  each  “view".  Figure  4 
illustrates  some  of  the  possibilities. 


Figure  4:  Rttektial  Cotceptual  (0,  Extbinal  0.  ajc  Internal  (I)  Levelling 


The  architecture  of  a  particular  DB*S  eay  include  any  number  of 
levels  (including  one  or  two  in  which  case  the  terms  external , 
conceotual  and  internal  do  not  readily  apply)*  Particular  levels 
may  fce  truly  £20£££iy2i*  ’•*•»  objects  are  never  realized  (as  was 
originally  intended  for  the  conceptual  level  of  the  ANSI 
architecture).  Per  example,  D"S110C  conceptual  objects,  those 
cefired  using  the  schema  DDL,  are  rever  realized.  Database 
objects  are  realizable  only  through  the  D*L  which  refers  to 
external  objects,  those  defined  using  subschema  ODL.  Ir  SYSTE"*-R 
however,  conceptual  objects  are  actual.  functions  can  be  applied 
to  (tase)  tables  tc  realize  them. 

3.2. 5 .  System  Objects 


System  objects  are  those  usea  by  the  DBhS  to  support  the  datj 
management  funetiens  over  the  external,  conceptual,  anc  internal 
objects  (e.g.,  access  profiles,  data  dictionaries*  system  logs, 
anc  massages).  Typically,  system  ctjects  are  defined  in  the 
system  and  are  modified  by  the  system  cnly.  future  DBMSs  may 
provide  more  control  over  system  objects.  For  example,  system 
objects  in  SYSTEM-*  ,  such  as  the  table  usea  to  store  information 
on  relations  in  the  database,  are  predefined  but,  with  the 
appropriate  authorisation,  can  be  modified,  fany  systems  provide 
some  definitional  facility  for  system  objects  through  system 
gene  ration. 


3.3.  .asic  DBMS  Otjects 


The  framework  provides  for  a  08*5  with  zero  or  more  of  each  type 
c*  level,  (e.g.,  multiple  external,  conceptual,  anc  internal 
levels  or  a  single  level).  Each  level  has  three  specific  kinds 
of  ctjects  associated  with  it:  data  objects  (database),  object 
descriptions  (schema),  and  function  cescriptions  for  pregram 
t r sr sf creat ions  over  the  database.  Ir  the  case  of  the  external 
level,  there  are  external  objects,  external  object  descriptions, 
anc  external  function  descriptions. 

The  basic  DBMS  objects  are  given  in  the  following  table: 
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E x  te  ma  l  Objects 


objects  of  interest  to  an 
app  l  icat  ion 


2*  External  object 
Descriptions 

3.  External  Function 
Descriptions 

<• .  Conceptual  Objects 


5.  Conceptual  Object 
Description 

fc.  Conceptual  Function 
rescript  ion 


7  .  Internal  Objects 


e  .  Internal  Object 
Description 

9.  Internal  Function 
Description 

1C.  Access  Profiles 


11.  Data  Dictionary 


1C.  System  Logs 


13.  Messages 


objects  which  define  external 
objects 

orograms  which  define 
application  functions 

objects  of  interest  to 
the  enterprise 

objects  which  define 
conceptual  objects 

programs  which  cefine 
conceptual  database 
functions 

objects  usea  to  implement 
conceptual  and  external 
objects 

objects  which  define 
external  otjects 

programs  which  define 
internal  functions 

objects  used  to  control 
access.  These  objects 
describe  the  conditions 
under  which  users 
(hu«en  or  programs)  can 
use  functional  components 
(i.e.t  what  language 
elenents,  functions,  and 
objects  are  accessable. 

objects  used  to  describe 
objects  in  the  CEPS 

objects  used  by  the  system  to 

monitor  and  maintain 

DBMS  objects  and  functions 

objects  passed  between 
Functional  components 


It  is  important  to  recall  that  a  DBMS  framework  is  a  generic 
ch a r ac te r  i  zat i on  of  DBMSs.  A  particular  DB"S  may  have  only  a 
Subset  of  the  above  objects  or  may  have  more.  The  objects 
presented  above  are  viewed  as  basic  to  a  DBMS. 


It  is  cossiMe  to  have  objects  whfch  describe  system  control 
objects  10  thru  13»  however  we  assume  that  these  are  virtual 
(e.c.,  no  functions  are  available  to  define  the*).  These  objects 
coulc  be  added  in  order  to  describe  a  DEWS  that  provides  such 
functional  components. 


3.*.  >?asic  Functions 


we  take  a  uniform  approach  to  DBMS  functions  in  which  we  apply  a 
set  of  basic  functions  to  all  objects  in  the  DFMS.  For  example 
the  approach  accomodates  modification  functions  over  database 
objects.  Object  and  program  description,  and  even  database  moael 
objects  (i.e,  the  constituent  objects  of  a  database  mooel). 
Current  D8MSs  support  the  mod i f i ca t i c r  of  database  objects.  (In 
self -organizing  systems  such  mod i f i c a t  i cn s  lead  to  mocification 
cf  schema  objects).  Some  systems,  e.g.,  SYSTE"-&,  support  the 
mocification  of  schema  objects.  Schema  modifications  leac  to 
modification  of  catabase  objects  but  ao  rot  (to  our  knowledge) 
lead  tc  nod i f i cat  i  cn s  of  database  mccel  objects.  A  research 
system  CHardgrave  and  Sibley  19793  supports  the  nooificaticn  of 
database  model  objects  (i.e.,  one  can  cefine  and  redefine  the 
uatatase  model).  Database  mccel  modifications  cause  modifications 
to  both  schema  and  database  objects.  Although  the  nature  of  the 
basic  functions  is  the  same,  their  effects  and  sice  effects  on 
the  various  objects  of  the  OEMS  vary  substantially.  That  is,  the 
semartics  of  the  functions  depena  on  the  nature  of  the  objects  to 
which  they  are  apolied. 

The  ten  basic  funct  icns  are: 


1 . 

Create 

initiate  or  estatlish  an  object 

C  9 

Cr  cp 

— 

elliminate  or  destroy  and  object 

t 

mr  9 

Associate 

enter  an  object  irto  some 
relationship  with  other  objects 
e.g.,  connect  one  object  to  anothtr. 

Di  ssociate 

remove  an  object  from  some 
relationship  with  other  objects, 
e.g.,  disconnect  cne  object  from  snot 

c 

~  • 

Lp  :a  t  e 

— 

modify  the  contents  of  an  object 

6. 

Derive 

deduce  and  create  an  object  from 
other  objects,  e.g.,  copy  is  the 
simplest  such  furctior. 

7. 

gu^ry 

read  and  present  cbjects  based  on 
logical  criteria,  e.g.,  search  anc 
di sol  ay 

L. 

Composite 
furC t  ion 

a  high  level  operation  defined  by 
structured  sequence  of  tasic 
funct  ions  1  to  7 . 

9. 

fie  po  r t 

generate  a  report  concerning  namec 
objects,  e.g.,  dump. 

10. 

Aoc  l  y 
Criterion 

apply  some  criteria  to  named  objects 
e.g  .  ,  ver i f i ca t i c r »  valioation. 
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stastical  analysis,  applying 
integrity  constraint. 


2.5.  Languages 


A  Urgtasjt  in  a  functional  component  has  two  purposes.  First, 
the  language  is  usee  to  express  functions  over  objects.  Second, 
the  language  is  used  to  initiate  or  prccuce  the  effect  of  the 
expressed  functions.  For  a  given  function  over  given  objects 
there  must  be  seme  syntax  for  their  expression.  whereas 
functions  and  objects  can  ce  described  abstractly,  language 
aspects,  i.e.,  syntax  is  more  concrete.  Hon  the  larguage  is 
implementeo,  e.g.  binding  time,  compilation  versus 
interpretation,  are  architectural  issues  net  addressee  in  the 
framework.  The  framework  does  not  imply  particular  language 
features  ,  rather  it  accommodates  a  spectrum  of  languages,  e.g., 
host,  self-  containea,  parametric.  The  framework  emphasizes  the 
importance  of  the  interface  the  language  provides  ana  the  need  to 
oescrite  the  interface  for  a  particular  DBMS, 


2.o.  Functional  Component  Matrix 


Each  ertry  in  the  following  matrix  (Figure  5)  incicates  a 
potential  functional  component  defined  by  language,  functions, 
anc  objects.  A  particular  D8MS  may  realize  a  basic  function 
through  one  of  more  language  statements. 


Figure -5:  Functional  Component  Matrix 


Again,  we  emphasize  that  the  external,  internal,  and  conceptual 
levels  can  be  repeated  zero  or  mere  times  as  needeo.  Also, 
objects  can  be  added  to  or  taken  out  of  the  framework.  the 
functional  components  described  above  are  considered  tasic  in  a 
pars ;  however,  the  frameworx  prov ices  for  the  adcition  of 
functional  components  which  may  be  user*definea. 

3.7.  Telat ionships  Between  functional  Components 


The  relationships  amongst  functional  components  is  an  important 
characteristic  of  any  c omput e r-b a s e c  system.  The  specific 
relationships  for  DBMS  have  been  eephasized  ty  researchers 

workin:  on  DBMS  architecture  in  general  ano  by  the  **«S1 

ar  c*1  it  ec  ture  in  particular.  Hence,  the  r  e  l  a  t  i  on  sh  i  p  s  must  be 
accommodated  in  the  DBMS  framework. 

Because  cf  the  abstract  nature  of  the  framework,  a  spectrum  of 

relationships  is  needed.  Consider  two  functional  components  a 

ana  *.  They  may  be  related  through  one  or  more  of  the  maos  or 
transforms  (indicated  by  ===)  in  figure  6. 


Figure  6:  Potential  Relationships  between  Functional  Components 


The  »acs  may  be  used  to  establish  equivalence,  derivation,  subset 
or  "uscs"  relationships  which  may  be  lexical  or  i*ple»ent at  tonal . 
Another  important  type  of  relationship  is  that  the  two  components 
may  te  grouped  to  form  one  component.  The  language  lx  may  man  to 
ly  or  -irectly  initiate  fy.  The  functions  f*  may  map  to  fy  or 
oirectly  ocerate  on  Oy.  finally,  the  object  Ox  can  be  maopeu 
directly  to  Oy  .  These  potential  relationships  apoly  to  all 
functional  components,  e.g.,  those  ter  database  objects,  object 
descriptions,  function  des c r i p t i ons ,  arc  system  control  objects. 
All  potential  relationships  will  be  incicated  in  the  framework  by 
the  couble  line  in  figure  7  which  is  mere  abstract  than  Figure  6. 


This  diagram  is  abstract  in  that  it  incicates  the  existence 
relationship  or  mac  but  not  HC«  the  map  is  to  be  realwea. 


Figure  7:  Functional  Component  Relationship  Schematic 
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A .  Functional  Analysis  of  Oc"Ss 


The  concepts  of  DBMS  framework  an c  DBMS  architecture  are 
orthogonal.  That  is,  given  functional  components  can  be 
implemented  in  different  a r c h  i  t e c t ur e s  and  a  given  architecture 
coulc  be  usea  tc  implement  different  functional  components.  A 
DBMS  framework  permits  the  analysis  cf  actual  and  potential 
DBMSs.  a  major  difference  between  DBMSs  is  the  way  in  which 
functional  components  are  aggregated  irto  system  components  for 
implementation  purposes  and  the  ways  in  which  the  system 
components  are  related.  The  architectual  issues  unnecessarily 
complicate  P8*S  cosparisons  and  DBMS  standards  development. 

The  functional  framework  can  te  appliec  to  DBMSs  i noepenoent  ly  of 
particular  ar ch i t e c t u res  .  Su b s eq ue r 1 1  y  ,  the  corresponding 
functional  components  can  be  composed,  again  indepencent  ly  of 
their  underlyino  architectures.  This  aralysis  has  been  done  for 
UNIVAC's  DMS  H'jC,  CODASYL's  1978  DDL,  ANSI/T3/H2's  DDL  ano 
SYSTEM  p  r u rod i e  19SC3. 

The  f  r  3mewor k  can  te  used  to  develop  system  architecture.  System 
recuirements  can  be  specified  in  terms  cf  functional  components. 
These  requirements  can  te  met  by  different  architectures. 
Architectural  design  decisions  concern  the  aggregation  of 
functional  components  into  system  components  and  the 
r e l a t i onsh ips  amongst  system  components.  Key  factors  in  these 
cec i si cns  are : 

(i)  modularity  and  layers  of  absraction  for  implementation 
and  maintenance  reasons,  i.e.  cata  inoependence; 

(ill  human  factors;  and 

liii)  the  desire  to  support  certain  'rules'  by 

providing  through  one  language,  the  functions  necessary 
to  fulfill  the-r-ole. 

The  functional  framework  can  be  used  tc  characterize  both  the 
f un c t i cn a  l  i  t y  and  architecture  of  systems.  For  e*ample,  mcst 
programming  language  systems  can  be  characterized  by  Figure  S. 
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The  relational  approach  to  databases  differs  fundamentally  with 
its  CODASYL  approach.  The  difference  may  be  illustrated  in  the 
functionality  of  SOL  and  03E.  following  Codo's  notion  of 
homogeneity,  the  distinction  between  DDL  and  D  M  L  is  not  as 
precise  as  in  the  CODASYL  approach.  Furthermore,  SOL  provides  a 
uniform  treatment  of  data  oojcets  arc  data  object  descriptions 
(schema).  That  is,  the  two  functional  components  in  the  CCD*SYl 
oiagrat  are  collapsec  into  one  as  is  illustrated  in  Figure  11  for 
the  languages  SQL  and  QBE  supported  by  SYSTEM  R  CBlasger  19793. 


SQL  QBE 


Figure  11:  SQL  and  Qbe  Functional  Components 

There  is  a  degree  cf  vertical  collapsing  in  System  R  since  there 
is  rot  a  clear  distinction  betweer  functions  and  relations, 
views  are  definec  (and  maintained)  as  functions  but  are 
considered  by  users  as  relations.  In  this  sense.  System  R  is  more 
similar  to  LISP  than  the  CODASYL  approach. 


Figure  12: (Partial.)  Architecture  of  System  R. 

In  SYSTEM  R,  RDS  (Relational  Data  System)  provides  the  functions 
ano  objects  realized  through  SQL  anc  QBE.  In  the  architecture 
schematic  (Figure  1?),  the  functions  FsqI  and  Fobe  have  been 
collapsed  as  well  as  the  objects,  however  the  languages  are 
ai st inct • 
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V  • 


Functional  Analysis  of  the  ANSI  Architecture 


In  this  section,  the  functional  framework  is  used  to 
charac  tf  rued  the  ANSI  architecture.  As  was  discussec  (Section 
2),  the  functional  approach  differs  free  that  taken  for  the  ANSI 
ar c h i t ®c t u r e .  Therefore,  the  following  conventions  are  used: 

(iT  anSI  interfaces  correspond  to  languages, 

(ii)  ANSI  roles  are  groupings  of  furctions  implemented 

by  the  processors  manipulated  ty  the  ANSI  processing 
fund  ion  . 


The  terminology  arc  "interface  numbers'*  are  taken  directly  from 
the  reports  £*N$I  1ST5;  Tsichritzis  and  Klug  1  5763.  for  bet  r 
brevity  and  abstraction,  the  roles  will  be  illustrated, 
interfaces  between  system  components  will  not  be  considered.  The 
charcterization  presented  here  is  purely  diagramatic;  it  lacks 
the  necessary  textual  descriptions  to  cefine  the  compenets  but 
which  can  be  fourd  in  the  reports.  The  ANSI  architecore  can  be 
ch  <j t  e  r  i  zeo  in  term  of  functional  components  and  their 
potential  rel at i o rs h  ips  .  Figure  13  illustrates  tnose  functional 
components  related  directly  to  database  ana  schema  objects. 
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Figure  14  illustrates  a  class  of  possible  architectures 


Figure  14:  Relationshios  In  the  ANSI  Architecture 
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To  be  consistent  with  the  A f.  I  architecture!  si 
a  soectrum  of  relationships  can  be  <  h  o  *  n  • 
detailed  functional  co*ccnent  schematic 
architecture. 
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Figure  15:  Functional  Schematic  of  the  ANSI  Architecture 


Conclusion 


t  . 


In  this  paper*  it  has  been  argued  that  analysis  an a  comparison  ot 
CBMSs  necessitates  an  abstract  DQ^S  characterization.  To  cate, 
such  analyses  anc  comparisons,  not  ally  the  ANSI  a r c h  i  t e c t u re  , 
have  teen  unne c e s s a r  i  l  y  complicatec  by  i mp  le m en at i on  or 
architectural  details.  Archittctura  l  indepenoenc e  as  well  as 
nine  other  requi resent s  for  a  DBMS  framework  were  discussed. 

The  cortrioutions  cf  this  paper  are  a  cistinction  between  DBMS 
framewcrk  and  DBMS  architecture,  and  a  functional  DBMS  framework. 
The  framework  was  developed  using  a  functional  approach  in  which 
a  computer  system  is  specified  abstractly  in  terms  of  functional 
components.  A  functional  component  consists  of  one  or  mere 
functions  over  defined  objects  with  some  form  of  abstract  syntax 
with  which  to  initiate  the  functions.  The  functional  approach 
adcresses  both  the  behavioral  and  structural  aspects  of  a 
computer  system.  The  approach  is  basec  on  notions  of  modularity 
ano  dafa  abstraction  developed  in  programming  language  anu 
software  engineering  research. 

The  advantages  of  the  functional  approach  apply  at  both  the 
aostract,  framewerk  level  and  the  i mp l ement a t ion  -o r i en t ed  , 
ar ch  it ec tural  level.  Indeec,  the  approach  was  oevelopec  to 
facilitate  the  design  of  computer  software  in  layers  of 
abstraction  from  a  u se r -o r i ent e d  abstract  level  down  to  an 
uncerlying  abstract  or  concrete  machine.  There  are  at  least 
eight  benefits*  c.t.  [Horning  19763: 


1.  Repetition 
«.'•  Modularity 

3.  S  tructure 
w.  Conceptual  Units 

5.  Specification 

6.  Maintenance 

7.  Eatension 

t .  Irdcpendence 


—  functional  components  can  be  definec 
once  and  used  repeateoly. 

—  the  concept  of  a  functional  component 
aids  in  decomposing  complex  systems 
into  meaningful  units. 

— •  functional  components  aid  in  the  design 
and  implementation  of  complex  systems. 

--  the  functional  approach  emphizes 

recuirements  cr  goals  (what)  rather  than 
specific  imp  1 e sen t a t  i on  (how)  which 
facilitates  un ce r s taro  i  ng  • 

—  a  functional  component  provides  an 
abstract  but  precise  specification  of 
the  properties  of  a  system. 

—  functional  components  aid  in  isolating 
and  correcting  errors. 

—  functional  components  can  be  used  tc 
add  new  components  to  a  system. 

—  functional  components  with  well 
defined  re l a t t ensh  ip s  support 
system  modi f  i  c *t ion  through  such 
features  as  separate  compilation. 


T  r 


The  functional  f raieworl  was  designeo  tc  fulfill  the  recuireeents 
set  for  03MS  frameworks*  The  framework  is  based  on  functions* 
objects*  and  languages  -  the  constituents  of  a  functional 
components  -  rather  than  being  based  on  specific  aggregations  of 
functions  into  rcles  with  interfaces  to  processors  that  operate 
on  implied  objects*  It  accommodates  a  spectrum  of  architectures 
since  it  is  indepenoent  of  architectural  issues.  In  particular* 
it  ac commodat es  a  spectrum  of  maps  rather  than  specific 
re l a t i cns h ips  which  determine  a  DBMS  architecture.  The  spectrum 
of  maps  permits  a  arbitrary  number  of  levels  of  e»ternal , 
conceptual*  ana  internal  schemas*  e.g.*  it  accommodates 


oistritutea  databases.  Schemas  defining  structure  and  behaviour 
are  supported.  The  approach  leads  to  and  accommooates  the 
evolving  concepts  of  data  d  i  ct ionary /d  i  rect ory  .  These  and  ether 
benefits  have  been  demonstrated.  A  acre  detailed  demonstration 
of  functional  anaysis*  including  the  use  of  the  functional 
component  matrix*  is  presented  in  CBrocie  198CJ. 

The  furctional  framework  also  satisfies  recuirements  proposec  for 
DBMS  architectures  in  CJeffery  et  at.  1979].  The  functional 
framework  emphasizes  components  and  is  simpler  than  the  *ASI 
architecture.  It  permits  c on cen t r a t i o r  on  specific  functional 
components  in  isolation.  The  functional  component  matrix 
includes  all  features  proposed  for  a  D6*S  and  provides  for 
user-oriented  components.  The  levels  of  abstraction  approach 
acccmmcdate  any  levels  of  “capability'*. 

An  investing  requirement  is  the  need  for  a  DBms  architecture  to 
accommodate  database  concepts  ana  termirology.  It  has  teen  shown 
that  the  functional  framework  accommodates  conventional  database 
concepts  and  terms,  e.g.*  those  introduced  by  the  ANSI 
architecture.  The  functional  framework  also  accommooates  the 
concept  of  database  model. 

Only  one  research  system,  the  aatabase  model  processor  [Hardgrave 
anc  Sibley  19^91  supports  the  defintior  of  new  datatase  mooets. 
This  concept  can  be  accommodated  in  the  functional  framework  by 
aJoirg  a  functional  component  for  database  models.  The  objects 
cf  such  a  component  are  the  generic  descriptions  of  schema 
objects*  e.3,  the  relation  and  tuple  ccrcepts  in  the  relational 
database  model  and  the  record  type  anc  set  type  concepts  in  the 
C 3 0 A S T l  model.  Some  subset  of  the  basic  functions  woulo  be 
defined  over  the  objects.  figure  If  represents  a  DPMS  with  a 
database  model  component. 
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figure  16:  Functional  Components  of  a  universal  DBMS 
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